2장. 결합과 복잡성: 커네빈

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 공식: https://www.jpub.kr/

원서: Balancing Coupling in Software Design (Manning) | https://www.manning.com/books/balancing-coupling-in-software-design

"결합이 적이 아니라면 무엇이 될 수 있을까? 복잡성이다. 이 짐승을 지배하려면 그 징조를 배워야 한다. 커네빈 프레임워크는 식별할 수 있는 경로를 보여준다." — 2장 도입부

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 복잡성(complexity)을 인지 부하 관점에서 설명한다.
• 커네빈의 다섯 도메인(명확·복합·복잡·혼돈·무질서)을 구분하고 각 도메인에 맞는 의사결정 방식을 매핑한다.
• WolfDesk 통합 시나리오를 읽고 해당 커네빈 도메인을 분류한다.
• 원인-결과 인과관계의 결합 강도로 도메인 경계를 판단한다.
• 설계 결정 전에 커네빈 도메인을 먼저 파악하는 습관을 적용한다.

전체 흐름도

[ 복잡성 = 시스템과 상호작용할 때 생기는 인지 부하 ]
        │
        ▼
[ 커네빈 프레임워크 — 5가지 도메인으로 상황을 분류한다 ]
        │
        ├─ 명확(Clear)       원인-결과 강하게 결합  →  감지-분류-대응
        │
        ├─ 복합(Complicated) 원인-결과 강하게 결합  →  감지-분석-대응
        │   (전문가 필요)                             (알려진 미지수)
        │
        ├─ 복잡(Complex)     원인-결과 약하게 결합  →  탐색-감지-대응
        │   (전문가 없음)                             (알 수 없는 미지수)
        │
        ├─ 혼돈(Chaotic)     원인-결과 분리됨        →  행동-감지-대응
        │   (예측 불가능)                             (본능 신뢰)
        │
        └─ 무질서(Disorder)  도메인 인식 불가        →  도메인 먼저 파악
                │
                ▼
        [ 소프트웨어 설계에 적용 ]
          "변경을 내리기 전에 지금 어느 도메인에 있는지 먼저 분류하라"

0. 사전 필수 용어

1. 복잡성이란? — 왜 정의부터 해야 하는가

1장에서 결합이 시스템의 접착제임을 배웠다. 그렇다면 시스템을 무질서하게 만드는 진짜 힘은 무엇일까? 저자의 답은 복잡성 (Complexity)이다.

스티븐 호킹이 "우리는 복잡성의 세기에 살고 있다"고 선언할 만큼 복잡성은 어디에나 있다. 금융 시장, 생태계, 교통 시스템 — 모두 복잡하다고 표현한다. 그런데 정확히 "복잡하다"는 게 무슨 뜻일까?

복잡성의 공식 정의

복잡성 = 사람이 시스템과 상호작용할 때 경험하는 인지 부하

인지 부하가 클수록: - 시스템이 어떻게 작동하는지 이해하기 어렵다. - 시스템을 제어하기 어렵다. - 미래 동작을 예측하기 어렵다. - 변경하는 데 더 많은 노력이 필요하다 — 소프트웨어 설계 관점에서 가장 중요한 효과.

복잡성은 주관적이다 — 누가 보느냐에 따라 다르다

복잡성의 수준은 관찰자에 따라 달라진다. 자동차 고장이라는 같은 상황도:

• 초보 운전자 → 며칠을 고민해도 원인을 못 찾는다. 복잡도 높음.
• 노련한 정비사 → 5분 만에 OBD 코드 읽고 원인을 잡는다. 복잡도 낮음.

같은 시스템, 다른 인지 부하. 이것이 복잡성이 주관적인 이유다.

이 사실이 중요한 이유는 — "이 시스템은 복잡하다/복잡하지 않다"는 절대적 판정이 불가능하다는 뜻이기 때문이다. 항상 "누구에게 복잡한가?"를 물어야 한다.

복잡한 코드베이스에서 벌어지는 일

잘못된 예 — 구성요소들이 뒤엉켜 있어 무엇을 고쳐야 할지 모름:

class OrderProcessor:
    def process(self, order_data):
        user = db.query("SELECT * FROM users WHERE id=%s", order_data["uid"])
        product = external_api.get(f"/products/{order_data['pid']}")
        sms_client.send(user["phone"], f"주문 {order_data['id']} 처리 중")
        email_lib.send(user["email"], "order_template", order_data)
        payment_gw.charge(user["card_token"], order_data["amount"])
        db.execute("INSERT INTO orders ...", order_data)
        cache.invalidate(f"user:{order_data['uid']}:orders")
        analytics.track("order_placed", order_data)

이 코드가 복잡한 이유: DB·외부 API·SMS·이메일·결제·캐시·분석 — 7개 외부 의존이 한 메서드 안에 엉켜 있다. "결제 실패 시 SMS 재발송" 같은 간단한 변경도 7개 경로를 다 따라가야 한다. 인지 부하 폭발.

올바른 예 — 각 구성요소가 단일 책임을 갖고 분리됨:

class OrderProcessor:
    def __init__(self, user_repo, product_repo, notifier, payment, analytics):
        self._user_repo = user_repo
        self._product_repo = product_repo
        self._notifier = notifier
        self._payment = payment
        self._analytics = analytics

    def process(self, order: Order) -> ProcessResult:
        user = self._user_repo.find(order.user_id)
        product = self._product_repo.find(order.product_id)
        result = self._payment.charge(user, order.amount)
        self._notifier.order_processed(user, order)
        self._analytics.track("order_placed", order)
        return result

결제 실패 처리를 바꾸고 싶으면 payment 객체만 본다. 7개 경로를 따라갈 필요가 없다. 인지 부하 급감.

2. 커네빈 프레임워크 — 복잡성을 5개 도메인으로 분류하다

복잡성을 "인지 부하"로 정의하는 것만으로는 소프트웨어 설계 결정을 내리기 부족하다. 더 정밀한 모델이 필요하다. 여기서 커네빈 (Cynefin)이 등장한다.

커네빈은 웨일스어로, 우리의 환경과 경험이 우리의 생각·해석·행동에 영향을 미치는 얽힌 요소들을 뜻한다. 데이브 스노든(Dave Snowden, 2007)이 의사결정 지원 도구로 공식화했다.

핵심 아이디어: 의사결정 상황을 다섯 도메인으로 분류하고, 각 도메인에 맞는 의사결정 방식을 선택하라.

언어 주의: 영어에서 "complex"와 "complicated"는 일상어로 동의어처럼 쓰인다. 커네빈은 이 둘을 엄격히 구분한다. "complicated = 복합(알려진 미지수)", "complex = 복잡(알려지지 않은 미지수)". 이 책과 이 노트에서도 커네빈의 정의를 따른다.

어원을 살펴보면 원래부터 다른 의미였다. complicated는 라틴어 'complicare(접힘)'에서, complex는 라틴어 'complexus(부분의 집합)'에서 유래한다.

3. 다섯 도메인 상세

3.1 명확한 도메인 (Clear Domain) — "규칙대로 하면 된다"

이전 버전의 커네빈에서는 '명백한(obvious)' 도메인으로 불렸다.

명확한 도메인에서는 행동의 결과가 분명하고 예측 가능하다. 원인-결과 관계가 강하게 결합되어 있다.

의사결정 방식: 감지 → 분류 → 대응

1. 감지: 사용 가능한 정보를 수집하고 관련 사실을 확립한다.
2. 분류: 사실을 사용하여 관련 규칙이나 모범 사례를 식별한다.
3. 대응: 선택한 규칙이나 모범 사례를 따른다.

잘못된 예 — 명확한 도메인에서 규칙을 무시하고 임의로 결정:

# 상태 코드를 직접 분기하지 않고 "대충 200이면 되겠지" 처리
def handle_response(status_code: int):
    if status_code >= 200:        # 잘못됨: 201·204·301도 통과함
        return process_success()

올바른 예 — 각 상태 코드별 규칙을 명시적으로 적용:

def handle_response(status_code: int):
    if status_code == 200:
        return process_success()        # 규칙: 200 = 성공
    elif status_code == 404:
        return handle_not_found()       # 규칙: 404 = 없음
    elif status_code == 401:
        return redirect_to_login()      # 규칙: 401 = 인증 필요
    elif status_code == 500:
        return show_server_error()      # 규칙: 500 = 서버 오류

어떤 상태 코드를 받든 결과가 명확하다. 규칙 테이블만 보면 된다.

WolfDesk 예시 — 명확한 통합 (원서 §2.4.1)

NotificationMaster의 SendSMS 메서드가 PhoneNumber 타입을 받고, 그 생성자 문서에 "E.164 국제 형식이어야 한다"고 명시되어 있다면 — 이것은 명확한 도메인이다.

SendSMS(PhoneNumber target, string message)
PhoneNumber.Constructor(string e164)  ← 형식이 문서에 명시됨

감지: PhoneNumber 생성자 문서를 읽는다.
분류: E.164 형식 = "+82-10-1234-5678" 같은 국제 표준 형식.
대응: E.164로 포맷해서 넣는다.

3.2 복합 도메인 (Complicated Domain) — "전문가에게 물어봐야 한다"

복합 도메인은 "알려진 미지수" 영역이다. 내가 무엇을 모르는지는 안다. 그래서 그 지식을 가진 전문가를 찾아 물어볼 수 있다.

의사결정 방식: 감지 → 분석 → 대응

1. 감지: 사용 가능한 정보를 수집하고 관련 사실을 확립한다.
2. 분석: 누락된 지식을 식별하고 관련 분야의 전문가와 상의한다.
3. 대응: 전문가의 조언을 따른다.

잘못된 예 — 전문가에게 묻지 않고 가정만으로 진행:

# 다른 팀이 DB를 쓰는 걸 알지만 "설마 영향 있겠어?"라며 인덱스 추가 → 배포
# 결과: 다른 팀 쿼리 성능 5배 저하

올바른 예 — 영향받을 수 있는 팀을 먼저 파악하고 분석 단계 거침:

감지: 다른 팀이 어떤 쿼리를 날리는지 파악한다.
분석: 다른 팀 리드에게 "이 인덱스 추가하면 너희 쿼리 성능에 영향 없어?" 묻는다.
대응: 전문가(다른 팀)의 피드백 반영해서 인덱스 추가/수정.

WolfDesk 예시 — 복합한 통합 (원서 §2.4.1)

SendSMS(string phoneNumber, string message) — 파라미터가 string 타입이라 형식이 불명확하다. 하지만 모듈 작성자에게 연락할 수 있다면? 복합 도메인.

감지: 어떤 전화번호 형식이 필요한지 파악한다.
분석: 모듈 작성자에게 "어떤 형식이야?"라고 묻는다.
대응: 작성자 답변에 맞는 형식으로 통합한다.

3.3 복잡한 도메인 (Complex Domain) — "실험해봐야 안다"

복잡한 도메인은 "알려지지 않은 미지수" 영역이다. 무엇을 모르는지조차 모른다. 아니면 알지만 아무도 그 지식을 갖고 있지 않다. 전문가가 없다.

더 나쁜 것은 — 행동의 결과가 맥락에 따라 달라진다. 일반 조언이나 모범 사례로는 예측할 수 없다. 어떤 행동을 하더라도 시스템 전체에 예측할 수 없는 변화를 초래할 수 있다.

의사결정 방식: 탐색 → 감지 → 대응

1. 탐색: 안전한 실험을 수행하여 결과를 관찰한다.
2. 감지: 실험 결과에서 패턴을 찾는다.
3. 대응: 실험 결과에 따라 행동을 결정한다.

중요: 복잡한 도메인에서 결과는 회고를 통해서만 추론할 수 있다. 먼저 행동해보고 관찰해야 한다. 실패를 학습 과정의 본질적인 부분으로 받아들여야 한다.

잘못된 예 — 실험 없이 확신으로 결정:

# "파란 버튼이 당연히 클릭률 더 높겠지" — 근거 없이 배포
# 결과: 파란 버튼 12%, 빨간 버튼 37%였음. 예측 실패.

올바른 예 — A/B 테스트로 안전한 실험 수행 (원서 §2.2.3, 그림 2.1):

class ABTestRouter:
    def __init__(self, experiments: dict):
        self.experiments = experiments  # {"btn_color": {"A": "red", "B": "blue"}}

    def assign(self, user_id: int, experiment: str) -> str:
        # 사용자를 50:50으로 분배 (안전한 실험)
        variant = "A" if user_id % 2 == 0 else "B"
        return self.experiments[experiment][variant]

# 탐색: 두 변형을 동시에 출시
router = ABTestRouter({"btn_color": {"A": "red", "B": "blue"}})
# 감지: 클릭률 데이터 수집 (12% vs 37%)
# 대응: 더 높은 클릭률의 변형 선택

WolfDesk 예시 — 복잡한 통합 (원서 §2.4.1)

SendSMS(string phoneNumber, string message) — 형식이 불명확하고, NotificationMaster가 레거시 시스템이라 작성자도 없고 소스도 없다. 유일한 방법은 시행착오.

탐색: 지역 번호로 시도 → 국제 번호로 시도 → 다양한 형식 시도.
감지: 어떤 형식이 성공하는지 관찰.
대응: 성공한 형식을 표준으로 삼고 문서화.

흥미로운 전환: 올바른 형식을 찾고 나면 이 시나리오는 복합 도메인으로 바뀐다. 이제 당신이 "전문가"가 되었기 때문이다. 다음 사람은 당신에게 물어보면 된다.

DB 인덱스 변경 — 복잡한 시나리오 (원서 §2.4.2)

다른 팀이 DB를 쓰는지 모르고, 자동화 테스트를 스테이징에 돌려서 결과를 관찰하기로 결정:

탐색: 스테이징 환경에 인덱스 변경 적용 + 자동화 성능 테스트 실행.
감지: 성능 점수 변화를 관찰.
대응: 성능이 좋아지면 프로덕션 배포, 나빠지면 롤백.

3.4 혼돈 도메인 (Chaotic Domain) — "지금 당장 탈출하라"

혼돈 도메인은 모든 것이 통제 불능인 상태다. 원인과 결과 사이에 식별 가능한 관계가 없다. 행동의 결과는 예측 불가능하거나 완전히 무작위다.

혼돈 도메인이 되는 두 가지 경우: 1. 본질적 예측 불가능: 주사위 던지기, 룰렛 — 아무리 실험해도 패턴을 찾을 수 없다. 2. 상황이 실험 자체를 불가능하게 만든다: 화재, 자연재해, 실시간 서비스 장애 — 실험할 시간이 없다.

의사결정 방식: 행동 → 감지 → 대응

1. 행동: 본능을 믿고, 위험에서 벗어나는 데 도움이 될 합리적인 행동을 취한다.
2. 감지: 행동의 결과를 관찰한다.
3. 대응: 위험에서 벗어났으면 다음 단계 계획. 아직 위험하면 다른 행동.

목표: 혼돈 도메인에서 복잡한 도메인으로 탈출하는 것. 위험에서 벗어난 후에야 분석이 가능하다.

잘못된 예 — 혼돈 상황에서 분석 우선:

# 배포 직후 관련 없는 서비스들이 타임아웃으로 줄줄이 실패
# 잘못된 대응: "오류 로그 분석 → 관련 코드 추적 → 그래프 보며 토론 → 20분 후 장애 악화"

올바른 예 — 분석보다 행동 우선, 안전 확보 후 분석 (원서 §2.4.2):

def handle_production_outage():
    # 행동: 직감을 믿고 최근 배포 롤백 (원인 분석보다 먼저)
    deploy_manager.rollback_latest()

    # 감지: 롤백 후 상태를 모니터링
    status = monitor.check_all_services()

    # 대응: 회복됐으면 안전 영역(복잡 도메인)에서 원인 분석
    if status.is_healthy():
        start_post_mortem_analysis()
    else:
        # 아직 혼돈 도메인 — 다른 행동 시도
        rollback_more_aggressively()

WolfDesk 예시 — 혼돈 통합 (원서 §2.4.1, 그림 2.4)

SendSMS(string phone, string message) — 레거시 시스템이고 형식도 모른다. 시행착오로 알아내려는데, 같은 형식인데 어떤 때는 성공, 어떤 때는 실패한다.

알고 보니 다른 버전의 서버가 로드 밸런서 뒤에 있었다 — 로드 밸런서가 서로 다른 API 서명(e164Number, phone, localNumber)을 가진 NotificationMaster 서버들로 요청을 분산하고 있었던 것이다.

결과가 무작위다. 실험 자체가 의미 없다. 혼돈 도메인.

대응: 본능을 믿고 → NotificationMaster 사용을 일단 중단 → 대안 SMS 공급자를 찾는다. 실험하고 분석할 안전한 자리로 먼저 나온다.

3.5 무질서 도메인 (Disorder Domain) — "내가 어느 도메인에 있는지 모른다"

무질서 도메인은 나머지 넷과 성격이 다르다. 현재 자신이 어느 도메인에 있는지 인식하지 못하는 상태다.

무질서 도메인에서 해야 할 일은 하나다: 지금 상황이 명확·복합·복잡·혼돈 중 어느 도메인인지 파악하라.

잘못된 예: 도메인 파악 없이 습관적으로 "전문가에게 물어봐"(복합 도메인 대응)만 반복. 실제로는 혼돈 도메인이라 전문가도 답을 모른다.

올바른 예: 멈추고 → "원인-결과 관계를 알 수 있나?" → "전문가가 있나?" → 도메인 분류 → 해당 의사결정 방식 적용.

참고: 커네빈 프레임워크 최신 버전은 무질서를 "아포리아(aporia, 한 명제에 대한 증거와 반증이 동시에 존재하여 진실성 확립이 어려운 상태)"와 "혼란(confusion, 상황을 잘못 분류하고 그 사실을 깨닫지 못하는 상태)"으로 세분화한다. 하지만 이 책은 단순화를 위해 두 가지를 구분하지 않는 버전을 따른다.

4. 결합과 복잡성의 연결 — 커네빈의 핵심 통찰

커네빈 프레임워크가 단지 철학적 분류 도구에 그치지 않는 이유: 원인-결과의 인과관계 결합 강도로 도메인을 나누기 때문이다. 이것이 1장의 결합 개념과 직접 연결된다.

그러므로: 복잡성은 행동과 결과 간의 느슨한 결합에서 비롯된다. 결합이 강할수록 예측 가능하고(명확), 느슨할수록 예측 불가능하다(복잡·혼돈).

이것이 저자가 1장에서 결합을 먼저 다루고 2장에서 커네빈으로 넘어온 이유다.

비유 — 레일과 오프로드

기차는 레일(강한 결합)을 따라 간다. 어디서 출발하면 어디에 도착하는지 완벽하게 예측할 수 있다. 명확한 도메인.

오프로드 차는 노면 상태에 따라 달라지는 경로를 간다. 어느 정도 예측 가능하지만 돌발 변수가 있다. 복합/복잡 도메인.

보트는 바람과 파도 위에서 간다. 경험 많은 선장도 정확히 어디에 도착할지 장담 못 한다. 복잡한 도메인.

핵심 개념 정리

실무 체크리스트

• [ ] 새 서비스나 라이브러리와 통합하기 전에 "지금 어느 커네빈 도메인인가?"를 팀과 명시적으로 확인했나?
• [ ] 복합 도메인임을 인식했을 때 전문가(내부 팀, 외부 문서, API 설계자)를 식별하고 연락했나?
• [ ] 복잡한 도메인에서 결과를 미리 예측하려 하지 않고 안전한 실험(스테이징·A/B·피처 플래그)을 설계했나?
• [ ] 혼돈 도메인(프로덕션 장애)에서 분석보다 행동(롤백·트래픽 전환·서킷 브레이커)을 먼저 실행했나?
• [ ] 복잡한 도메인에서 실험으로 지식을 얻은 후, 그 지식을 문서화해서 복합 도메인으로 승격시켰나?
• [ ] 설계 결정을 내리기 전에 해당 시나리오의 인과관계 결합 강도를 명시적으로 따졌나?
• [ ] "이 변경이 다른 팀/서비스에 미칠 영향을 예측할 수 있나?"를 자문해서 도메인을 분류했나?

연습문제 (문제만 — 정답은 부록 D)

1. 개념. 복잡성(complex)과 복합성(complicated)의 커네빈 정의 차이를 한 문장씩 써라. 일상 영어 의미와 어떻게 다른가?

2. 분류. 다음 각 시나리오가 커네빈의 어느 도메인에 속하는지 답하고, 해당 의사결정 방식(3단계)을 적어라.

3. (a) 팀 내 MySQL 마이크로서비스에 새 인덱스를 추가한다. 이 DB는 이 마이크로서비스만 사용한다.

4. (b) 레거시 결제 게이트웨이 문서가 없고 담당자도 퇴사했다. 어떤 API 호출이 성공할지 알 수 없다.

5. 적용. 당신 팀이 새 머신러닝 추천 엔진을 실서비스에 도입하려 한다. "클릭률이 개선될지" 사전에 아무도 확신하지 못한다. 커네빈 관점에서 어느 도메인이고, 어떤 의사결정 프로세스를 취해야 하는가?

6. 비교. 복잡한 도메인에서 지식을 얻으면 시나리오가 복합 도메인으로 전환된다고 본문이 설명한다. 소프트웨어 설계 실무에서 이 전환을 의도적으로 만드는 방법을 두 가지 제시하라.

7. 판단. 프로덕션에서 예상치 못한 장애가 발생했다. 팀원 A는 "로그부터 분석하자"고 하고, 팀원 B는 "일단 롤백부터 하자"고 한다. 커네빈 관점에서 누가 더 올바른 접근인가? 이유를 설명하라.

최신 동향 (검증 2026-05-31)

• 커네빈 프레임워크는 2007년 데이브 스노든의 공식화 이후 핵심 구조가 안정적으로 유지되는 프레임워크다. 최신 버전에서 무질서 도메인을 "아포리아(aporia)"와 "혼란(confusion)"으로 세분화하는 방향으로 정교화가 진행 중이다. 공식 자료: cynefin.io
• 소프트웨어 엔지니어링 실무에서 커네빈의 활용 범위가 넓어지고 있다. 팀 레트로스펙티브, 아키텍처 의사결정(ADR), 사고 대응(incident response) 프로세스 설계에 커네빈 도메인 분류를 명시적으로 도입하는 조직이 늘고 있다.
• HBR 원문(2007) — 스노든이 커네빈을 경영진 의사결정 도구로 소개한 논문: A Leader's Framework for Decision Making

부록 A. 용어 사전

부록 B. 핵심 비교표

표 2.1 커네빈 프레임워크 네 도메인 비교 (원서 표 2.1 인용·확장)

WolfDesk 통합 시나리오 비교 (원서 §2.4.1)

DB 인덱스 변경 시나리오 비교 (원서 §2.4.2)

부록 C. 추천 참고 자료 & 링크

Tier 1 공식·표준

추가 자료

책 다른 장 안내

부록 D. 연습문제 풀이

1. (복잡 vs 복합 정의)

• 복합 (Complicated): "알려진 미지수" — 무엇을 모르는지 안다. 전문가를 찾으면 해결 가능하다. 일상 영어에서는 "complicated = 어렵다"의 의미로 쓰이지만 커네빈은 "전문가가 있는 어려움"으로 한정한다.
• 복잡 (Complex): "알려지지 않은 미지수" — 무엇을 모르는지조차 모른다. 실험 없이는 결과를 예측할 수 없다. 일상 영어에서는 "complex = 복잡하다"지만 커네빈은 "실험 없이는 예측 불가능한 불확실성"으로 한정한다.
• 차이: 일상 영어에서 두 단어는 동의어처럼 쓰이지만, 커네빈은 불확실성의 수준과 해결 방법이 근본적으로 다른 두 상태로 구분한다. complicated는 더 공부하거나 전문가를 부르면 해결되고, complex는 아무리 공부해도 실험 없이는 답을 모른다.

2. (시나리오 분류)

• (a) 팀 내 MySQL 마이크로서비스 + 이 DB만 사용: 명확한 도메인. 이 DB를 사용하는 구성요소가 자신의 마이크로서비스뿐이고, 어떤 쿼리가 영향받는지 완전히 알고 있다. 의사결정 방식: 1) 감지 — 인덱스 변경 영향을 받는 쿼리를 파악, 2) 분류 — 기존 쿼리 성능 변화 예측, 3) 대응 — 인덱스 추가.
• (b) 레거시 결제 게이트웨이 + 담당자 퇴사 + 문서 없음: 복잡한 도메인. 어떤 API가 어떤 조건에서 성공하는지 알 수 없고 전문가도 없다. 의사결정 방식: 1) 탐색 — 다양한 파라미터 조합으로 스테이징 환경에서 호출 실험, 2) 감지 — 성공·실패 패턴 수집, 3) 대응 — 신뢰할 수 있는 호출 방식 문서화 후 적용.

3. (머신러닝 추천 엔진 도입)

복잡한 도메인. "클릭률이 개선될지"를 아무도 확신할 수 없고, 맥락(사용자 군, 콘텐츠, 시간대)에 따라 결과가 달라진다. 일반 모범 사례로 예측 불가.

의사결정 프로세스: - 탐색: 피처 플래그 또는 A/B 테스트로 전체 사용자의 10%에게만 새 추천 엔진 노출. - 감지: 클릭률·체류 시간·전환율 데이터를 수집하고 통계적 유의성 확인. - 대응: 개선이 확인되면 단계적으로 100% 트래픽으로 확대; 개선 없으면 모델·피처 수정 후 재실험.

4. (복잡 → 복합 전환 방법)

• 지식 문서화: 시행착오로 얻은 지식(어떤 형식이 작동하는지, 어떤 API 호출이 성공하는지)을 팀 위키나 ADR로 기록한다. 다음 사람은 실험 없이 문서를 읽으면 된다. 실험자가 "전문가"가 되어 복합 도메인이 형성된다.
• 테스트 코드화: 실험으로 발견한 성공 케이스를 자동화 테스트로 만든다. 테스트가 통과하면 "이 동작은 안전하다"는 지식이 코드베이스에 내재된다. 이후 변경 시 테스트가 안전망이 되어 복합 도메인 수준의 예측 가능성을 제공한다.

5. (장애 대응 — 로그 분석 vs 롤백)

커네빈 관점에서 팀원 B(롤백 우선)가 더 올바르다.

프로덕션 장애는 혼돈 도메인의 전형적 사례다. 원인이 불분명하고 상황이 시시각각 악화될 수 있다. 혼돈 도메인에서의 올바른 접근은 분석보다 행동을 먼저. 로그 분석(감지-분석-대응 = 복합 도메인 접근)은 혼돈 도메인에서는 위험을 키울 수 있다.

롤백으로 위험에서 벗어난 뒤 — 서비스가 안정되면 그제야 로그를 분석하고, 원인을 파악하고, 재발 방지 대책을 세운다. 이 순서가 커네빈의 행동-감지-대응과 일치한다. 분석은 안전한 복합/복잡 도메인에서 한다.